\subsection{Challenges}
\label{sec:Challenges}

%This Section identifies several challenges that \textsc{Mds} faces, motivated by the previous example. 

\subsubsection{Expressiveness}
\label{sec:Expressiveness}

The previous rules already cover a large spectrum: \textsf{R1} is a \emph{permission}; \textsf{R2} and \textsf{R3} are \emph{obligations}; and \textsf{R4} is a \emph{prohibition}. Furthermore, \textsf{R3} and \textsf{R4} depend of \textsf{R2}'s compliance of the doctor, i.e. they become relevant only if \textsf{R2} is violated. A current challenge in \textsc{Mds} is to include in the security model constructs enabling the specification of all these different types of rules. Currently, most of the approaches \cite{Basin2007a,Mouelhi2008,Morin2010a,Basin2011} deal with access control models, which prevent them from capturing many requirements mainly obligation requirements such as those found in \textsc{Hipaa}, \textsc{Glba} and \textsc{Coppa} (Children's Online Privacy Protection Act) \cite{Mont2004a,May2006,Barth2006,Barth2007,Ni2008,Lam2009}.

\vspace{-0.5cm}
\subsubsection{Abstraction}
\label{sec:Abstraction}

The example rules do not specify how the different artifacts involved are actually represented in their enforcement environment: for example, an action like \textsf{delete} or \textsf{submit} may actually involve several methods whose parameters can depend on each others. Abstraction is actually a very desirable property for enabling simple and intuitive rule expression and interpretation. Furthermore, it is often the case that organisations have to comply with mandates generally specified at a high abstraction level, sometimes close to natural language. Keeping this practice and providing a mechanism for matching these constructs to the execution environment is another important challenge.


\vspace{-0.5cm}
\subsubsection{Separation Of Concerns}
\label{sec:SoC}

The rules presented above do not depend on the implementation of system's functionalities nor the particular environment they need to be enforced in. This separation of concerns clarifies the policy specification, and is a key enabler for policy reuse within different platforms, or different organisations. It becomes necessary when security officers are different from business logic developers. 


\vspace{-0.5cm}
\subsubsection{Mapping}
\label{sec:Mapping}

Although the specification of a security policy should be separated from its enforcement environment, it is necessary to provide a clear and unambiguous interpretation of the policy by providing a way to precisely map artifacts of security rules to artifacts of the target architecture. In our example, an \emph{administrative} file, or what is precisely intented by \emph{encrypted} file is left abstract. Similarly, the policy uses a vocabulary that does not necessarily correspond to the concepts used in the implementation.

This link is unfortunately often missing when policies are separated from their targets, as it is typically the case for \textsc{Xacml} policies. What generally happens in this case is that developers have to manually devise the queries to the \textsc{Xacml} security component for decision-making each time an access request is needed. This link is not clearly documented, and usually spread over the application code, which makes the policy enforcement semantics obscure and more vulnerable to security breaches. Providing a full-fledged language with an associated semantics may help overcoming this point.



\vspace{-0.5cm}
\subsubsection{Violation Monitoring \& Reaction}
\label{sec:ViolationMonitoringReaction}

How to enforce rules like \textsf{R5}? As a matter of fact, it is not possible to enforce the deletion of a file, and automatic measures may be unsafe. Some security requirements are difficult, or even impossible, to actually enforce within a system. A lightweight solution consists in monitoring system's artifacts and to simply detect the fulfillment/violation of a security rule instead of directly enforcing it. This shows how crucial it is to enable system's monitoring, but this also has a cost: efficient monitoring should not hinder system performance drastically, and should not open security holes. 

\vspace{-0.5cm}
\subsubsection{Policy Runtime Updating}
\label{sec:PolicyRuntimeUpdating}

It is often important to enforce new rules, or to relax already existing ones. Therefore, an important feature of a security policy language is the ability of having rules depending on other ones. This dependence can be specified \emph{a priori}, like the \textsf{R3} and \textsf{R4} do in our example. Organisations are live institutions that evolve: new internal regulations can appear, or old regulations can change, sometimes drastically. For example in our case, if a monthly report is judged too costly, this can be relaxed as a two-months basis. The ability to integrate new security rules and/or to update existing ones is an important aspect that should find a counterpart in the security language to guarantee the continuation of services and to minimise policy updates costs. Unfortunately, most \textsc{Mds} approaches focus on design time models, before the security policy is deployed over the system.

\vspace{-0.5cm}
\subsubsection{Security Infrastructure Generation} 
\label{sec:InfrastructureGeneration}

For enabling full code generation, \textsc{Mds} uses model transformations, generally performed after an analysis phase. A first approach spreads security concerns within the business model (e.g. using \textsc{Uml} extended with profiles or stereotypes \cite{Jan2002,Lodderstedt2002}), and the generated infrastructure consists of one logical entity after model transformations. The other approach consists in keeping security concerns separated from business logic, with the so-called \textsc{Pep/Pdp} (Policy Enforcement Point / Policy Decision Point) approach, and both interact for security decisions (e.g., \textsc{Xacml} policies generation from security models). A major issue in this context lies in keeping models synchronised: changes at the model level are expected to be automatically and correctly deployed at the infrastructure level.
